home *** CD-ROM | disk | FTP | other *** search
/ IRIX 5.3 for Indy R4400 / IRIX 5.3 for Indy R4400 175MHz.img / relnotes / c++_eoe / chA.z / chA
Text File  |  1995-02-28  |  2KB  |  67 lines
  1.  
  2.  
  3.  
  4.                                   - 1 -
  5.  
  6.  
  7.  
  8.        1.  _D_y_n_a_m_i_c__S_h_a_r_e_d__O_b_j_e_c_t_s
  9.  
  10.        A Dynamic Shared Object, or DSO, is an ELF format object
  11.        file, very similar in structure to an executable program but
  12.        with no "main".  It has a shared component, consisting of
  13.        shared text and read-only data; a private component,
  14.        consisting of data and the GOT (Global Offset Table);
  15.        several sections that hold information necessary to load and
  16.        link the object; and a liblist, the list of other shared
  17.        objects referenced by this object. Most of the libraries
  18.        supplied by SGI are available as dynamic shared objects.
  19.  
  20.        A DSO is relocatable at runtime; it can be loaded at any
  21.        virtual address.  A consequence of this is that all
  22.        references to external symbols must be resolved at runtime.
  23.        References from the private region (.e.g. from private data)
  24.        are resolved once at load-time; references from the shared
  25.        region (e.g. from shared text) must go through an
  26.        indirection table (GOT) and hence have a small performance
  27.        penalty associated with them.
  28.  
  29.        Code compiled for use in a shared object is referred to as
  30.        Position Independent Code (PIC), whereas non-PIC is usually
  31.        referred to as non-shared.  Non-shared code and PIC cannot
  32.        be mixed in the same object.
  33.  
  34.        At Runtime, eeeexxxxeeeecccc loads the main program and then loads rrrrlllldddd,,,,
  35.        the runtime linking loader, which finishes the exec
  36.        operation.  Starting with main's liblist, rrrrlllldddd loads each
  37.        shared object on the list, reads that object's liblist, and
  38.        repeats the operation until all shared objects have been
  39.        loaded.  Next, rrrrlllldddd allocates common and fixes up symbolic
  40.        references in each loaded object.  (This is necessary
  41.        because we don't know until runtime where the object will be
  42.        loaded.)  Next, each object's _i_n_i_t code is executed.
  43.        Finally, control is transferred to "__start".
  44.  
  45.        For a more complete discussion of DSOs, including answers to
  46.        questions frequently asked about them, see the _d_s_o(_5) man
  47.        page.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.